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About  the  Technical  Note  Series  on  Business  and 
Acquisition  Guidelines 


The  Product  Line  Systems  Program  is  publishing  a  series  of  technical  notes  on  product  line 
acquisition  and  business  practices  for  the  DoD  acquisition  manager  and  practitioner.  Each 
technical  note  will  focus  on  one  aspect  of  adopting  software  product  line  practice  in  the 
Department  of  Defense.  Our  objective  is  to  provide  practical  guidance  to  early  DoD  adopters 
on  ways  to  integrate  sound  product  line  practices  into  their  acquisitions.  By  investigating  and 
reporting  best  commercial  and  government  practices,  the  SEI  is  covering  new  ground  in 
overcoming  the  challenges  and  increasing  the  understanding,  maturation,  and  transition  of 
software  product  lines. 

This  series  of  technical  notes  will  lay  down  a  conceptual  foundation  for  DoD  product  line 
business  and  acquisition  practices  that  are  consistent  with  the  product  line  framework  of  the 
SEI  [Clements  00]. 

While  we  intend  each  technical  note  to  be  distributed  and  read  as  a  standalone  document,  a 
brief  overview  of  software  product  lines  is  provided  in  Software  Product  Lines :  A  New 
Paradigm  for  the  New  Century  [Clements  99].  If  you  are  not  familiar  with  this  introductory 
material,  we  recommend  you  read  it  before  reading  this  technical  note.  Other  information 
from  the  SEI  on  product  line  practices,  including  the  latest  version  of  the  Framework  for 
Software  Product  Line  Practice ,  is  available  at 
http://www.sei.cmu.edu/activities/plp/plp_init.html. 
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Abstract 


Industrial  experience  clearly  demonstrates  that  a  product  line  approach  for  software-intensive 
systems  can  save  money  and  result  in  faster  time  to  field  higher  quality  systems.  Many  within 
the  DoD  recognize  the  benefits  of  product  lines,  but  also  recognize  that  there  are  significant 
challenges  to  adopting  such  an  approach.  One  of  several  challenges  that  confront  a  DoD 
organization  is  developing  and  implementing  a  suitable  acquisition  strategy.  To  be  effective, 
the  DoD  organization  must  balance  its  product  line  aspirations  against  the  ability  of  potential 
contractors  (having  varying  levels  of  product  line  experience  and  “hands-on”  knowledge  of 
related  legacy  systems)  to  meet  its  needs.  It  also  must  balance  them  against  the  requirements 
of  DoD  policy  and  regulatory  documents  that  govern  the  entire  acquisition  process. 

Several  key  questions  are:  “What  does  developing  an  acquisition  strategy  involve?”  and 
“How  does  a  DoD  organization  develop  an  effective  strategy  for  acquiring  a  software  product 
line?”  This  case  study  focuses  on  a  recent  effort  that  shows  how  one  DoD  organization 
answered  these  questions. 

This  technical  note  describes  the  approach  a  DoD  organization  used  to  develop  alternative 
acquisition  strategies  and  analyzes  the  pros  and  cons  of  each.  It  summarizes  the  acquisition 
context.  It  also  presents  a  number  of  alternative  product  line  acquisition  strategies,  a  method 
for  comparing  the  merits  of  each  approach,  and  some  risk  reduction  measures.  Although  this 
case  study  purposely  disguises  the  actual  organization  and  product  line,  it  reflects  the 
considerations  involved  in  developing  a  software  product  line  acquisition  strategy. 
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1  Introduction 


Software  product  lines  represent  a  new  way  of  developing  a  related  set  of  software  systems. 
In  contrast  to  building  systems  one-at-a-time,  in  a  stand-alone  manner,  the  practice  of 
building  sets  of  related  systems  from  common  software  assets  can  yield  remarkable 
quantitative  improvements.  These  improvements  may  be  measured  in  terms  of  productivity, 
time  to  market,  product  quality,  and  customer  satisfaction  [Clements  00]. 

In  this  case  study,  we  examine  a  DoD  organization  that  is  struggling  to  upgrade  existing 
stove-piped  avionics  systems.  Rising  software  maintenance  costs  and  the  increasing 
obsolescence  of  its  legacy  computing  platforms  (embedded  in  these  systems)  are  stymieing 
the  organization’s  ability  to  implement  new  mission  capabilities  and  enhancements  at  a 
reasonable  cost.  Rather  than  continue  to  maintain  separate  development  programs  for  each 
avionics  system,  the  organization  sees  consolidation  of  software  development  and 
maintenance  into  a  single  product  line  as  a  means  to  accomplish  several  business  goals: 

•  Reduce  development  and  maintenance  costs. 

•  Increase  reliability  and  quality  of  fielded  products. 

•  Ease  the  integration  of  new  computing  platforms  and  interfaces. 

•  Enable  faster  implementation  of  new  capabilities  and  system  enhancements. 

In  this  technical  note,  we  describe  how  a  DoD  organization  developed  an  acquisition  strategy 
to  commission  a  software  product  line1  for  a  family  of  integrated  avionics  systems.  We  have 
disguised  the  identities  of  the  DoD  organization  and  the  legacy  system  contractors  to  protect 
the  privacy  of  all  those  involved.  We  will  simply  refer  to  the  DoD  organization  as  the  “SPO” 
and  the  product  line  being  acquired  as  the  DoD  Avionics  Software  Product  Line  or  DoD 
“ASPL.” 

In  Section  2,  we  provide  background  information  on  the  SPO’s  legacy  system  environment  to 
set  the  context  for  their  product  line  acquisition.  Next,  we  describe  the  approach  that  the 
organization  used  for  developing  and  analyzing  alternative  acquisition  strategies.  Following 
this,  we  describe  relevant  planning  assumptions,  five  candidate  acquisition  strategies,  the 
methodology  used  for  analyzing  them,  and  the  results.  An  example  plan-of-action  for 
implementing  one  of  these  acquisition  strategies  is  presented  next,  along  with  a  means  for 
reducing  the  acquisition  risk.  Last,  we  provide  a  summary  with  conclusions. 


1  A  software  product  line  is  a  set  of  software-intensive  systems  sharing  a  common,  managed  set  of 
features  that  satisfy  the  specific  needs  of  a  particular  market  segment  or  mission  and  that  are 
developed  from  a  common  set  of  core  assets  in  a  prescribed  way. 
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2  Legacy  System  Context  for  Acquiring  a  Product  Line 


The  SPO  has  software  life-cycle  responsibility  for  three  functionally  related  systems.  The 
SPO  envisioned  creating  a  software  product  line  to  replace  the  legacy  software  of  the  three 
systems  under  their  purview.  We  will  refer  to  these  systems  as  “System  A,”  System  B,”  and 
“System  C.”  The  avionics  software  for  these  systems  and  their  variants  corresponds  to  the 
future  products  in  the  ASPL. 

Table  1,  which  is  an  excerpt  from  the  product  line  scoping1  report,  characterizes  these  future 
software  products  in  terms  of  their  high-level  commonality  and  variability. 


Table  1:  Future  Products  in  the  DoD  Integrated  Avionics  Software  Product  Line 


System  Version 

Software  Product  Characteristics 

System  A 

Full  set  of  interfaces;  80%  of  all  features  within  product  line  scope 

System  B, 

Variant  1 

80%  of  interfaces;  60%  of  all  features  within  product  line  scope 

System  B, 

Variant  2 

Same  interfaces  as  System  B,  Variant  1;  all  features  of  System  B, 
Variant  1,  plus  features  within  product  line  scope  not  in  System  A 

System  C 

40%  of  interfaces;  scaled  back  version  of  System  B,  Variant  2 

Each  instance  of  the  DoD  ASPL  would  be  a  software  product  that  provided 

•  a  set  of  integrated  services  that  encompasses  flight  management,  communications, 
navigation,  and  display  capabilities 

•  the  ability  to  insert  new  technologies  across  platforms  significantly  faster  and  more 
cost  effectively 

•  the  means  for  efficient  system  integration  and  increased  functionality  with  minimal 
impact  on  the  baseline  operator  interface 


As  indicated  in  Table  1,  all  the  systems  deliver  very  similar  capabilities  to  users.  They  differ, 
however,  along  several  variation  points  corresponding  to  the  legacy  computing  system 

1  Scoping  bounds  the  product  line  by  identifying  the  commonality  that  products  share  and  the  ways 
in  which  the  products  vary  within  the  product  line. 
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platform,  the  number  of  features  they  provide,  and  the  number  and  types  of  external 
interfaces. 

By  exploiting  the  commonality  of  the  avionics  requirements  across  these  three  classes  of 
systems,  the  SPO  can  significantly  reduce  software  development  costs  and  technical  risk.  The 
SPO  can  also  reduce  the  time  and  effort  needed  for  test  and  integration,  scheduling,  logistical 
support,  and  training. 

Two  companies  are  currently  under  contract  to  the  SPO  for  software  maintenance  and 
enhancement  of  these  legacy  systems.  One  company  is  responsible  for  legacy  System  A  and 
the  other  company  is  responsible  for  legacy  System  B.  To  conceal  their  identities,  we  will 
refer  to  these  contractors  simply  as  “ACON”  and  “BCON”  respectively. 

•  ACON  is  the  original  developer  of  the  System  A  avionics  software.  It  used  a  traditional 
system  development  approach  that  resulted  in  a  custom  software  implementation.  The 
software  includes  major  assembly  code  that  has  been  extensively  modified  over  time  to 
accommodate  government-specified  enhancements. 

•  BCON  is  the  original  developer  of  the  System  B  avionics  software.  Its  development 
approach  was  novel.  It  adopted  a  company-proprietary  product  line  approach,  using  a 
common  software  architecture  and  other  reusable  core  assets,  to  develop  the  System  B 
software.  Since  System  B  was  developed  after  System  A  was  operational,  more 
complete  specifications  were  available  to  develop  System  B  resulting  in  significantly 
fewer  modifications.  System  B  software  is  written  in  a  modem  high  order  language. 

Both  ACON  and  BCON  are  on-site  contractors.  They  are  required  to  use  special  test 
facilities  to  integrate  and  test  new  software  system  builds  prior  to  certifying  them  for 
operational  use.  Ideally,  the  SPO  would  like  both  of  these  legacy  contractors  to  be  involved  in 
any  future  product  line  initiative  because  of  their  domain  expertise  and  knowledge  of  the 
existing  systems,  avionics  software,  and  test  facilities. 

To  support  its  mission,  the  SPO  uses  other  local  contractors  and  an  in-house  engineering 
contingent  to  perform  systems  and  software  tasks  such  as  requirements  engineering,  analysis, 
and  testing. 
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3  Product  Line  Vision 


In  the  current  legacy  system  environment,  the  SPO  must  direct  ACON  and  BCON  to  develop 
unique  software  to  implement  any  new  requirement  that  is  common  to  both  organizations.  In 
effect,  the  government  is  paying  twice  to  implement  desired  software  changes. 

In  the  proposed  DoD  ASPL,  new  software  will  be  developed  once,  then  integrated  into  the 
target  avionics  systems  in  a  pre-planned  and  predictable  manner.  Thereafter,  the  common 
software  will  be  centrally  managed  and  sustained  over  the  life  of  the  product  by  one  software 
organization  or  contractor.  This  is  consistent  with  the  SPO’s  goal  to  acquire  a  software  product 
line  capability  for  a  family  of  avionics  systems  that  can  replace  its  existing  legacy  systems. 


Figure  1  represents  the  steady-state  operation  of  the  envisioned  product  line  following  the 
acquisition  of  a  product  line  software  architecture  and  a  start-up  set  of  core  assets. 


New  System 
Requirement 
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Sustainment 
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Refinement 


Architecture 


Components 


Production 

Plan 


New  Asset 
Development 


Product  Development’1 
and  Sustainment 


Product 
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Product 

Production 


Product 

Production 


Product  B 


Product  C 


*  Includes  development  of  product-unique  components 


Figure  1:  Responding  to  New  System  Requirements  in  a  Product  Line  Approach 


To  achieve  this  vision,  the  SPO  needed  to  acquire  an  initial  product  line  capability.  The 
acquisition  was  also  to  include  commissioning  the  development  of  the  first  avionics  software 
product  having  features/performance  equivalent  to  legacy  System  A.  This  would  involve 
mining  legacy  system  assets  to  recover  the  functionality  and  mission-specific  features 
embodied  in  that  system.  Figure  2  provides  an  overview  of  what  this  type  of  acquisition 
involves. 
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Figure  2:  Conceptual  View  of  Elements  Involved  in  SPO’s  Product  Line  Acquisition 

In  keeping  with  this  conceptual  view,  the  SPO  established  three  goals  that  were  essential  to 
its  product  line  acquisition  and  the  envisioned  set  of  avionics  software  products: 

1 .  There  must  be  a  core  software  asset  base.  These  assets  must  cover  interfaces  and 
features  in  terms  of  requirements,  architecture,  components,  and  a  production  plan 
necessary  to  generate  the  actual  products  (i.e.,  the  avionics  operational  software)  from 
these  core  assets. 

2.  There  must  be  an  efficient  system  integration  capability.  The  current  approach 
requires  too  much  rework  to  integrate  new  platforms,  interfaces,  or  features. 

3.  There  must  be  a  system  structure  to  ensure  cross-platform  insertion  of  new  product 
features.  The  product  line  architecture,  by  design,  must  accommodate  cross-platform 
insertion  of  new  or  changed  functionality  with  minimal  impact  to  current  user  interfaces. 

Once  the  vision  and  the  goals  were  established,  the  SPO  formed  a  team  to  develop  an 
acquisition  strategy  for  acquiring  a  core  asset  base  for  the  ASPL  and  for  products  built  from 
it.  This  effort  is  depicted  in  Figure  2.  In  conjunction  with  developing  an  acquisition  strategy, 
a  business  case  was  developed.1  It  compares  the  costs  and  benefits  of  the  current  way  of 
developing  software  systems  against  those  of  a  product  line  approach. 


1  The  business  case  effort  is  described  in  a  separate  study  [Cohen  01]. 
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4  Acquisition  Strategy  Definition 


Unlike  industry.  DoD  and  government  organizations  are  required  to  comply  with  federal 
policy  documents  and  regulations  that  govern  the  entire  acquisition  process.  DoD  5000.2-R,  a 
high-level  DoD  acquisition  regulation,  describes  an  acquisition  strategy  as  being  the  road 
map  “to  guide  program  execution  from  initiation  through  re -procurement  of  systems, 
subsystems,  components,  spares,  and  sendees  beyond  the  initial  production  contract  award 
and  during  post-production  support"  [DoD  5000.2-R].  This  acquisition  strategy  is  event- 
driven  and  corresponds  to  the  management  approach  that  a  Program  Manager  (PM)  will 
establish  for  controlling  and  executing  a  major  acquisition  program.  1  This  program-level 
acquisition  strategy  corresponds  to  a  higher  tier  strategy  and  is  significantly  different  than  the 
acquisition  strategy  that  is  the  focus  of  this  case  study.  For  example,  DOD  5000.2-R  contains 
over  100  individual  requirements  governing  the  development  of  an  acquisition  strategy. 

Our  definition  of  an  acquisition  strategy  is  more  pragmatic  and  is  applicable  to  any  life-cycle 
phase  of  an  acquisition  program.  We  define  an  acquisition  strategy  as  a  plan  of  action  for 
achieving  a  specific  goal  or  result  through  contracting  for  software  products  and  services 
[Bergey  99J.  This  definition  is  consistent  with  the  Federal  Acquisition  Regulation  and  the 
SEI’s  Software  Acquisition  Capability  Maturity  Model  (SA-CMM)  [FAR  97,  Cooper  99].  A 
PM  can  roll  this  acquisition  strategy  into  the  program-level  acquisition  strategy.  This  plan  of 
action  includes  all  the  steps  required  to  commission  (i.e.,  contract  for)  a  set  of  core  assets — 
chief  of  which  is  a  product  line  architecture — and  the  derivative  products  built  from  those 
assets.  This  is  consistent  with  the  SPO’s  goal  to  acquire  a  software  product  line  capability  for 
a  family  of  avionics  systems  to  replace  the  existing  legacy  systems,  and  subsequently  to  pave 
the  way  for  incorporating  future  enhancements  at  lower  cost  and  risk  over  the  life  of  the 
systems. 
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Guidance  on  developing  such  a  program-level  acquisition  strategy  is  available  from  several 
sources  [DSMC  99.  SAMP  00], 
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5  Developing  and  Analyzing  Alternative  Acquisition  Strategies 


To  address  the  SPO’s  goals  for  acquiring  a  software  product  line,  an  acquisition  team  was 
formed  that  included  members  of  the  SPO’s  staff  and  representatives  from  the  operational 
units  using  the  avionics  systems.  Team  meetings  were  held  over  a  two-month  period  and 
were  facilitated  by  the  SEI.  The  SEI  representatives  provided  guidance  and  helped  to 
structure  an  approach  for  developing  and  analyzing  alternative  acquisition  strategies.  The 
value  judgments  that  were  made  in  the  process  of  analyzing  and  evaluating  different 
acquisition  approaches  were  those  of  the  DoD  organizations  involved  and  not  those  of  the 
Software  Engineering  Institute. 

The  acquisition  team  examined  not  just  one,  but  several  alternative  acquisition  strategies.  By 
taking  this  approach,  the  team  was  able  to  assure  the  SPO’s  high-level  management  that  all 
options  were  being  considered  and  that  no  particular  acquisition  approach  was  being  forced 
on  them.  Identifying  alternatives  also  provided  management  with  insight  into  the  overall 
program  impact  of  each  strategy  and  what  tradeoffs  and  risks  were  involved. 

The  following  steps  summarize  the  approach  that  the  acquisition  team  took  to  develop  a 
software  product  line  acquisition  strategy: 

1.  Understand  the  motivation  for  the  product  line  initiative  and  its  scope. 

a.  determine  the  sponsor’s  vision  and  goals  for  the  product  line  acquisition 

b.  understand  the  product  line  scope  and  its  relationship  to  any  baseline  legacy 
systems  that  will  eventually  be  supplanted  by  future  products  from  the  product  line 

2.  Capture  management  guidance  and  planning  assumptions  that  will  guide  or  constrain  the 
product  line  acquisition. 

3.  Explore  candidate  acquisition  approaches  that  can  satisfy  the  product  line  vision  and 
acquisition  goals  commensurate  with  the  product  line  scope  and  other  relevant 
management  guidance  and  planning  assumptions. 

4.  Establish  the  major  programmatic  and  technical  drivers  that  will  govern  the  acquisition 
approach  and  ultimately  determine  its  suitability. 

5.  Analyze  and  evaluate  the  efficacy  of  each  candidate  course  of  action  using  the  major 
drivers  identified  in  the  previous  step. 

6.  Recommend  a  product  line  acquisition  strategy  and  develop  a  corresponding  plan  of 
action  for  pursuing  the  strategy. 

7.  Produce  a  report  summarizing  the  findings  and  recommendations  so  that  higher  level 
management  can  determine  whether  the  recommended  acquisition  strategy  best  satisfies 
the  organization’s  needs. 
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5.1  Understanding  the  Product  Line  Acquisition  Context 

Accomplishing  the  first  step  involved  eliciting  and  understanding  the  background 
information  described  earlier  in  Sections  2  and  3.  The  process  consisted  of  attending 
briefings  that  described  the  organization’s  planning  and  analysis  effort  for  the  product  line 
initiative  and  having  follow-up  discussions.  These  briefings  relied  heavily  on  the  expertise  of 
the  individuals  who  previously  conducted  the  product  line  scoping  effort  [Cohen  01].  The 
individuals  gave  the  acquisition  team  a  good  understanding  of  the  SPO’s  vision  and  goals  for 
the  product  line.  They  also  described  the  product  line  scope  and  its  relationship  to  current 
legacy  system  baselines. 

5.2  Establishing  Acquisition  Guidance  and  Planning  Assumptions 

Having  obtained  this  background  information,  the  team  next  captured  guidance  provided  by 
SPO  management  and  documented  any  planning  assumptions  pertinent  to  the  acquisition. 
Table  2  summarizes  some  examples  of  management  guidance  and  planning  assumptions. 


Table  2;  Guidance  and  Planning  Assumptions  for  SPO’s  Product  Line  Acquisition 


Example  Guidance/Planning  Assumptions 

1. 

Product  line  effort  will  focus  on  delivering  a  product  with  System  A  functionality  within  three 
years. 

2. 

Any  loss  of  System  A  core  features/functionality  is  not  acceptable  (i.e.,  performance  is  a  given). 

3. 

Product  line  approach  must  accommodate  System  A  user  interface  compatibility. 

4. 

All  embedded  mission  computers  will  be  replaced  coinciding  with  initial  product  delivery. 

5. 

Since  effort  is  not  aligned  with  other  programs,  new  funding  sources  must  be  pursued. 

6. 

One  potential  source  of  funding  for  the  product  line  initiative  is  currently  a  line  item  in  the  POM. 

7. 

Current  legacy  system  Post  Deployment  Software  Support  (PDSS)  contracts  will  remain  in  place. 

8. 

Incumbent  contractors  can  perform  supporting  technical  analyses  under  existing  PDSS  contracts. 

9. 

The  System  B  legacy  software  is  proprietary  (i.e.,  owned  by  the  development  contractor)  but  the 
government  owns  the  rights  to  the  System  A  legacy  software. 

10. 

The  SPO  will  seek  government  data  rights  to  all  product  line  software  assets  including  the 
architecture. 

11. 

All  products  must  be  deliverables  to  the  government  regardless  of  the  acquisition  strategy  chosen. 

12. 

Future  avionics  enhancements  are  beyond  the  scope  of  the  initial  System  A  product  development. 

Explicitly  recording  the  guidance  and  assumptions  was  a  necessary  step  to  ensure  that  the 
acquisition  team  was  “on  the  same  page”  as  management  and  had  a  common  understanding 
of  the  expectations  and  ground  rules  for  the  product  line  acquisition. 
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5.3  Developing  Candidate  Courses  of  Action 

The  acquisition  team  considered  various  contracting  approaches  for  acquiring  a  product  line. 
This  involved  exploring  tradeoffs  between  using  fixed-price,  cost  reimbursement,  incentive, 
indefinite  delivery,  time  and  materials,  labor  hours,  letter  contracts,  and  even  basic  ordering 
agreements.  These  constitute  the  range  of  permissible  types  of  contracts  as  described  in  Part 
16  of  the  Federal  Acquisition  Regulation  (FAR).  The  FAR  provides  general  guidance  and 
outlines  the  conditions  for  using  each  of  these  different  types  of  contracts.  Since  the  FAR 
governs  all  DoD  and  government  acquisitions,  every  acquisition  strategy  must  use  one  (or  a 
combination)  of  these  basic  types  of  contracts  and  award  fee  structures. 

After  strategizing  and  considering  the  pros  and  cons  of  various  approaches,  the  team  devised 
four  basic  contractual  approaches  that  could  potentially  fulfill  the  SPO’s  goals  for  acquiring  a 
software  product  line.  These  four  basic  contractual  approaches  (i.e.,  Pre-Qualify,  Sole  Source, 
Fly-Off,  Open  Acquisition)  translated  into  five  candidate  courses  of  action  (CO As)  that  are 
summarized  in  Table  3. 


Table  3:  Candidate  Courses  of  Action  (COA)  for  Acquiring  a  Product  Line 


Candidate  Courses  of  Action  (COA) 

ID 

Descriptive  NAME 

Contractual  Approach 

COA 

#1 

PRE-QUALIFY  multiple 

contractors  awarded 

contracts  and  collaborate  in 

effort 

Competitive  award  of  2  or  3  task  order  contracts  to  multiple 
offerors  to  collaborate  in  product  line  and  product  development 
(i.e.,  an  avionics  software  system)  in  accordance  with  pre- 
established  source  selection  criteria. 

COA 

#2A 

SOLE  SOURCE 

to  ACON:  System  A 

software  contractor 

Sole  source  award  of  a  single  task  order  contract  to  one  of  the 
incumbent  software  contractors  to  develop  a  software  product  line 
and  a  baseline  product.  These  two  mutually  exclusive  choices  are 
explored  to  consider  the  impact  of  one  legacy  software  contractor 
being  selected  over  another. 

COA 

#2B 

SOLE  SOURCE 

to  BCON:  System  B 

software  contractor 

COA 

#3 

FLY-OFF 

resulting  in  award  of  single 

contract  to  best-value 

performer 

Competitive  award  of  two  or  three  short  term  contracts.  Have 
selected  offerors  compete  in  a  “fly-off”  development  effort  leading 
to  the  award  of  a  single  task-order  contract  to  the  offeror 
demonstrating  “best  value”  performance. 

COA 

#4 

OPEN  Acquisition 
single  contract  award 

Competitive  award  of  a  single  task  order  development  contract  to 
the  offeror1  submitting  the  “best  value”  proposal. 

1  It  is  an  offeror's  prerogative  to  represent  a  single  contractor  or  a  contractor  team. 
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Each  of  these  COAs  is  compatible  with  commissioning  a  product  line  capability,  including  a 
product  line  architecture,  common  software  components,  and  other  core  assets  required  to 
build  a  family  of  software  products.  The  first  avionics  software  product  to  be  acquired  would 
have  features  and  performance  equivalent  to  legacy  System  A.  The  design  of  the  core  assets 
would  support  the  software  commonality  and  variability  of  other  planned  avionics  software 
products  that  are  within  the  product  line  scope. 

The  common  denominator  for  all  of  these  COAs  is  a  contracting  approach  based  on  an 
indefinite  delivery/indefinite  quantity  (ID/IQ)  task  order  contract.  An  ID/IQ  task  order 
contract  is  the  best  fit  since  the  exact  times  and  quantities  of  future  deliveries  are  unknown 
and  there  is  a  recurring  need  for  services.  With  other  contract  types,  the  SPO  would  have  to 
commit  to  more  than  a  minimum  quantity  and  additional  funding  would  be  required  at  the 
time  of  contract  award.  This  could  significantly  increase  the  acquisition  risks  and  create 
funding  problems.  The  ID/IQ  task  order  contract  also  allows  for  other  risk  mitigation 
measures  to  be  easily  included.  We  will  present  these  in  a  later  section. 

5.4  Identifying  the  Major  Acquisition  Drivers 

To  assist  in  analyzing  and  evaluating  which  course  of  action  might  be  the  most  effective,  the 
acquisition  team  identified  a  number  of  crucial  acquisition  drivers.  These  major  drivers  are 
the  key  programmatic  and  technical  considerations  that  will  direct  the  course  of  the 
acquisition  and,  ultimately,  determine  the  suitability  of  one  approach  over  another. 

Table  4  lists  a  set  of  major  drivers  used  in  this  case  study.  All  of  these  drivers  fell  in  the 
category  of  being  essential  or  highly  desirable.  Their  order  generally  reflected  the  SPO’s 
relative  priorities  and  concerns. 


Table  4:  Major  Drivers  Used  to  Analyze  Impact  of  Candidate  Courses  of  Action 


Major  Acquisition  Drivers 

1. 

Contractor(s)  will  have  access  to  all  legacy  software. 

2. 

Contractor(s)  will  have  relevant  expertise  to  be  able  to  leverage  GFIl  legacy  software. 

3. 

Acquisition  approach  will  have  the  potential  to  involve  both  legacy  system  contractors. 

4. 

Contractor(s)  will  be  totally  responsible  for  avionics  software  performance. 

5. 

Acquisition  approach  will  be  compatible  with  schedule  constraints. 

6. 

The  SPO  can  acquire  eovemment-use  data  rights  for  all  product  line  assets. 

7. 

Acquisition  approach  will  reduce  risk  of  acquiring  a  product  line  capability. 

8. 

Likelihood  of  being  able  to  avoid  a  protest  that  could  impact  acquisition  schedule 

9. 

SPO’s  perception  of  the  affordability  of  the  approach  (based  on  historical  cost  data) 

1  The  System  A  software  would  be  provided  as  a  Government  Furnished  Item  (GFI)  to  the  product 
line  development  contractor  who  is  awarded  the  contract. 
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In  effect,  these  major  acquisition  drivers  represent  the  criteria  for  analyzing  the  suitability  of 
the  candidate  courses  of  action  and  indicate  some  of  the  acquisition  tradeoffs  that  are 
involved.  Therefore,  it  was  important  that  the  team  have  a  common  understanding  of  these 
drivers  and  how  they  could  affect  the  acquisition.  To  facilitate  this  understanding,  the  team 
diligently  discussed  and  described  each  of  the  drivers.  These  descriptions  provided  insight 
into  the  nature  of  the  need,  or  concern,  that  the  acquisition  driver  is  addressing.  Several 
examples  follow: 

•  Driver  #1.  Contractor(s)  will  have  access  to  all  legacy  software. 

The  SPO  does  not  have  data  rights  to  the  System  B  legacy  software.  As  a  result,  another 
contractor  cannot  be  given  the  System  B  source  code  to  extract  the  functionality,  design, 
or  operation  of  that  system.  On  the  other  hand,  the  government  owns  System  A  software 
and  can  provide  it  to  another  contractor  as  a  government-furnished  item  (GFI).  Ideally, 
the  product  line  contractor  should  have  access  to  both  the  System  A  and  System  B  legacy 
software  if  it  is  to  implement  a  product  line  approach  (based  upon  current  capabilities)  in 
a  timely  and  cost-effective  manner.  Only  the  System  B  contractor  potentially  has  access 
to  System  B  legacy  software.  Even  its  use  on  a  different  contract  may  require  company 
approval. 


•  Driver  #2.  Contractor(s)  will  have  relevant  expertise  to  leverage  GFI  legacy  software. 

The  issue  is  whether  the  winning  contractor  will  have  the  domain  expertise,  technical 
skills,  tools,  and  experience  needed  to  effectively  leverage  the  existing  System  A 
software.  The  SPO  anticipates  that  any  contractor  other  than  the  incumbents  will  have  a 
steep  learning  curve  and  may  not  be  able  to  effectively  leverage  the  GFI  System  A 
software.  Even  System  A  contractor  may  face  a  challenge  in  leveraging  the  assembly- 
level  code  that  is  part  of  its  own  software  because  it  was  developed  independently  by  a 
sub-contractor.  The  objective  in  leveraging  the  GFI  software  is  to  accurately  capture 
System  A  functionality1  so  that  a  set  of  reusable  software  components  (and  related  assets) 
can  be  developed  that  are  fully  compatible  with  a  product  line  approach  and  faithfully 
replicate  the  capabilities  of  System  A  software.  Another  objective  in  leveraging  the 
existing  code  is  to  implement  an  equivalent  capability  at  a  cost  and  schedule  less  than 
that  required  for  a  start-from-scratch  development  effort. 


•  Driver  #3.  Acquisition  approach  will  have  the  potential  to  involve  both  legacy  system 
contractors. 

It  would  be  ideal  if  both  legacy  system  contractors  were  collaborating  on  the 
development  of  a  product  line  capability.  This  is  due  to  the  fact  that  one  contractor  has 

1  The  term  “functionality”  is  used  in  a  very  general  sense  as  fully  encompassing  the  current 
capabilities  and  features  of  the  System  A  software. 
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specialized  knowledge  of  and  experience  with  product  lines  and  product  line 
architectures,  while  the  other  contractor  has  unique  knowledge  of  and  experience  with 
the  System  A  software  that  is  the  “avionics  system  of  choice.”  However,  since  the 
government  cannot  force  a  collaborative/teaming  relationship,  it  can  only  promote  the 
possibility  of  such  an  arrangement  by  the  way  it  structures  the  acquisition. 


•  Driver  #6.  SPO  can  acquire  government-use  data  rights  for  all  software  assets. 

Acquiring  government-use  data  rights  for  all  software  assets  is  desirable  for  three  very 
important  reasons: 

-  First,  it  can  avoid  a  situation  in  which  one  contractor  (e.g.,  BCON)  has  a  virtual  lock 
on  software  life-cycle  support. 

-  Second,  it  will  enable  the  government  to  have  other  contractors  independently  develop 
and  integrate  software  into  other  mission  critical  subsystems  and  technologies  in  the 
product  line  family  of  systems. 

-  Third,  in  the  future,  it  will  potentially  enable  the  government  to  provide  the  software 
to  other  contractors  to  competitively  develop  new  product  line  assets  (e.g.,  reusable 
software  components)  and  support  new  mission  requirements  (i.e.,  extend  the  product 
line).  One  cautionary  note  is  that  a  contractor  may  be  very  reluctant  to  sell 
government-use  data  rights  if  it  believes  that  other  contractors  will  obtain  visibility 
into  their  proprietary  product  line  operations  and  core  assets.  Such  an  arrangement 
could  potentially  compromise  the  contractor’s  competitive  edge  in  the  marketplace.  In 
these  cases,  contract  negotiations  may  provide  the  only  avenue  that  could  lead  to  an 
acceptable  solution. 


5.5  Analyzing  and  Evaluating  the  Candidate  Courses  of  Action 

In  this  step  of  the  process,  the  team  meticulously  analyzed  the  five  candidate  courses  of 
action.  This  involved  evaluating  the  potential  ability  of  each  course  of  action  to  satisfy  the 
major  drivers  identified  in  the  previous  step.  The  acquisition  team  members  relied  on  their 
corporate  knowledge  and  expertise  on  the  subject  matter,  historical  data,  and  common  sense 
to  perform  the  analysis  and  reach  a  consensus.  The  team  used  Red  (R),  Yellow  (Y),  and 
Green  (G)  indicators  to  summarize  the  findings  and  present  them  to  upper  management. 
These  indicators  are  explained  below: 


Indicates  that  the  candidate  COA  will  probably  not  satisfy  the  acquisition  driver. 

Indicates  that  it  is  marginal  or  questionable  whether  the  candidate  COA  can 
satisfy  the  particular  acquisition  driver.  These  concerns  (i.e.,  yellow  indicators) 
potentially  may  be  satisfied,  or  overcome,  via  the  contract  negotiation  process. 
However,  if  they  are  not  resolved  some  of  them  they  potentially  may  become 
“show-stoppers”  corresponding  to  red  indicators. 


Indicates  that  the  candidate  COA  will  most  likely  satisfy  the  acquisition  driver. 
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Table  5  summarizes  the  analysis  of  all  the  CO  As.  It  indicates  the  projected  effect  of  the  major 
acquisition  drivers  on  each  candidate  course  of  action. 


Table  5:  Summary  of  Impact  of  Acquisition  Drivers  on  Candidate  CO  As 


PRE-QUALIFY 

O 

i  > 

SOLE  SOURCE 

n 

o  w 
z 

FLY-OFF 

OPEN  Acquisition 

Business/ Acquisition  Drivers 

COA 

#1 

COA 

#2 -A 

COA 

#2-B 

COA 

#3 

COA 

#4 

1.  Contractor(s)  will  have  access  to  all 
legacy  software. 

© 

2.  Contractor(s)  will  have  relevant 
expertise  be  able  to  leverage  GFI 
(ACON)  software. 

© 

E3 

© 

© 

3.  Acquisition  approach  will  have 
potential  to  involve  both  legacy 
system  contractors. 

■allSifU- 

© 

© 

4.  Contractor(s)  will  be  totally 

responsible  for  avionics  software 
performance. 

© 

© 

© 

5.  Acquisition  approach  will  be 
compatible  with  schedule 
constraints. 

© 

© 

© 

© 

© 

6.  The  SPO  can  acquire  government- 
use  data  rights  for  all  product  line 
assets. 

© 

© 

© 

© 

7.  Acquisition  approach  will  reduce 
risk  of  acquiring  a  product  line 
capability. 

© 

© 

© 

© 

© 

8.  Likelihood  of  being  able  to  avoid  a 
protest  that  could  impact  acquisition 
schedule 

© 

y 

© 

© 

9.  The  SPO’s  perception  of  the 

affordability  of  approach  (based  on 
historical  cost  data) 

N/A 

© 

N/A 

N/A 
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A  brief  explanation  of  each  red  and  yellow  indicator  was  included  with  the  summary.  For  this 
technical  note,  we  will  explain  the  rationale  for  one  of  the  Red  indicators,  driver  #4  under 
COA#i. 

COA#J  (PRE-QUALEFY)-Since  this  strategy  involves  awards  to  multiple  contractors,  no 
single  contractor  will  have  total  responsibility  for  the  performance  of  the  avionics  software 
product.  Instead,  the  government  will  have  de-facto  responsibility  and  “finger  pointing” 
among  contractors  can  be  expected  should  problems  arise. 

It  is  important  to  point  out  that  no  one  course  of  action  will  satisfy  all  the  drivers  as  all  the 
COAs  involve  significant  tradeoffs.  For  example,  if  the  selected  course  of  action  involves 
multiple  contractors,  as  in  COA#l,  then  clearly,  no  single  contractor  will  have  total 
responsibility  for  all  the  contractual  work.  Consequently,  the  SPO  has  to  tradeoff  the  desire  to 
have  both  incumbent  contractors  involved  (because  of  their  extensive  knowledge  of  the 
legacy  software)  against  the  desire  to  have  one  contractor  assume  total  responsibility  for  the 
system. 

The  cost  driver  (i.e.,  the  SPO’s  perception  of  the  affordability  of  the  proposed  COA)  is  only 
applicable  to  COAs  #2A  and  #2B  because  historical  cost  data  exists  only  for  these  options 
that  directly  relate  to  the  existing  legacy  software  contractors. 

5.6  Recommending  an  Acquisition  Strategy  and  Establishing  a  Plan 
of  Action 

In  this  case  study,  the  acquisition  team  did  not  recommend  a  particular  course  of  action. 
Instead,  due  to  the  sensitive  nature  of  the  acquisition  and  the  tradeoffs  involved,  it  reported 
on  all  the  candidate  courses  of  action  with  the  understanding  that  management  would  make 
the  final  decision.  Tradeoffs  needed  to  be  considered  because  there  were  compelling 
arguments  for  selecting  a  sole  source  acquisition  strategy  and  compelling  arguments  for 
selecting  a  competitive  acquisition  strategy.  For  example,  the  following  arguments  could  be 
made  for  selecting  COA  #4: 

•  promotes  open  competition 

•  is  consistent  with  a  tight  schedule 

•  is  potentially  the  lowest  cost  approach 

•  offers  the  most  balanced  approach  for  meeting  the  organization’s  stated  goals 

•  is  the  least  likely  course  of  action  to  result  in  a  protest 

However,  all  the  COAs  offered  unique  benefits  and  all  of  them  (including  COA  #4  cited 
above)  included  at  least  one  red  indicator: 

•  COA  #1.  No  single  contractor  would  have  total  responsibility  for  the  end-product. 
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•  COA  #2A  and  #2B.  The  risk  of  a  contractor  filing  a  protest  is  higher  and  that  could 
adversely  impact  the  schedule. 

•  COA  #3.  Despite  its  desirability,  a  competitive  fly-off  involves  extra  time  and  costs  and 
is  incompatible  with  the  program’s  cost  and  schedule  constraints. 

•  COA  #4.  Contractors  will  only  have  access  to  the  GFI  software  and  not  the  CMS 
software  that  reflects  a  product  line  approach. 

As  a  result,  SPO  management  requested  that  the  acquisition  team  brief  them  on  each  COA. 


Defining  a  Plan  of  Action 

Had  the  team  recommended  a  course  of  action,  the  next  step  would  be  defining  a  plan  to 

carry  it  out.  The  following  example  plan  of  action  applies  to  the  open  competition  acquisition 

strategy  (e.g.,  COA  #4)  and  consists  of  six  steps: 

1 .  The  SPO  will  task  the  legacy  contractors  (under  their  existing  contracts)  to  jointly  define 
a  conceptual  architecture  for  the  software  product  line  and  develop  a  requirements 
specification  for  the  DoD  ASPL. 

2.  In  parallel  with  Task  1,  the  SPO  will  form  an  ASPL  Integrated  Project  Team  (IPT)  to 
refine  the  product  line  scope,  specify  the  conceptual  architecture,  develop  the 
requirements  specification,  and  gather  the  documents  that  will  be  provided  as  GFI. 

3.  After  Task  1  is  complete,  the  ASPL  IPT  will  analyze  the  deliverables  produced  under 
Task  1  and  selectively  integrate  those  elements  that  will  enhance  and  elaborate  the  work 
products  developed  under  Task  2.  [This  will  assist  the  SPO  in  developing  a  more 
complete  and  robust  specification  that  will  reduce  the  risk  of  having  to  amend  the  RFP 
during  the  solicitation  period  and  enhance  the  likelihood  of  acquiring  a  higher  quality 
product .] 

4.  In  parallel  with  the  preceding  tasks,  the  acquisition  team  will  develop  an  acquisition  plan 
for  an  open  competitive  procurement  using  an  ID/IQ  contracting  approach,  and  execute 
the  plan.  The  acquisition  plan  will  refine  the  acquisition  strategy,  develop  a  work 
breakdown  structure  describing  the  acquisition  tasks,  and  develop  a  detailed  schedule 
with  measurable  milestones.  [This  will  assist  the  SPO  in  achieving  an  action-oriented 
acquisition  strategy,  ensure  everyone  is  on  the  “same  page,  ”  enhance  the  team ’s  ability 
to  stay  focused  and  develop  the  RFP  on  schedule,  and  meet  the  organization’s  overall 
acquisition  goals.] 

5.  The  acquisition  team  will  integrate  the  enhanced  work  products  developed  by  the  ASPL 
IPT  into  the  RFP,  complete  Sections  C,  J,  L,  and  M  of  the  RFP1,  and  develop  a  source 
selection  plan.  [This  will  complete  preparation  of  the  RFP  and  enable  the  Contracting 
Officer  to  begin  the  formal  solicitation.] 


1  Sections  C,  J,  L,  and  M  correspond  to  the  Statement  of  Work  (SOW)  and  Specifications,  List  of 
Contract  Deliverables,  Proposal  Preparation  Instructions,  and  Evaluation  Factors  for  Award, 
respectively. 
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6.  A  source  selection  team  will  evaluate  the  offerors’  proposals  (in  accordance  with  the 
source  selection  plan)  and  competitively  award  a  single  contract  to  develop  the  DoD 
ASPL  capability  and  common  architecture  leading  to  the  delivery  of  a  new  version  of 
System  A  using  the  product  line  architecture  and  components.  [This  will  complete  the 
award  phase  and  begin  the  contract  management  and  performance  phase  that  will  lead 
to  the  development  of  the  specified  contract  deliverables.  Having  a  rigorous  acquisition 
plan  and  a  judicious  source  selection  plan  will  reduce  the  risk  of  any  bona  fide  protest 
being  filed  by  an  offeror] 

Developing  a  plan  of  action  for  a  different  acquisition  strategy  would  involve  adapting 
elements  of  this  plan  of  action. 

5.7  Preparing  an  Acquisition  Strategy  Summary  Report 

The  last  step  consisted  of  documenting  the  findings  and  presenting  them  to  management  for 
review  and  approval.  In  this  case  study,  all  the  candidate  acquisition  courses  of  action  were 
presented  to  management  since  the  team  was  not  asked  to  recommend  a  specific  one,  but 
rather  to  present  the  pros  and  cons  of  each.  The  acquisition  team  was  aware  that  the 
management  review  was  going  to  be  more  than  perfunctory.  In  fact,  management  ultimately 
chose  a  different  acquisition  strategy  based  on  extenuating  circumstances  that  were  beyond 
its  control  and  changed  the  scope  of  the  acquisition. 

The  acquisitions  team’s  report  included  much  of  the  same  information  as  presented  in  this 
technical  note.  An  explanation  of  the  team’s  findings  and  a  management  presentation  were 
built  around  the  tables  presented  here.  The  description  of  each  candidate  course  of  action 
included  an  explanation  of  each  red  and  yellow  indicator  to  clarify  the  nature  of  the  impact. 

Once  management  approves  an  acquisition  strategy,  implementing  the  strategy  will  often 
involve  two  teams  as  outlined  in  the  hypothetical  plan  of  action  above.  Ideally,  an  acquisition 
team  should  be  formed  to  have  overall  responsibility  for  planning  all  aspects  of  the 
acquisition  and  integrating  all  the  sections  that  make  up  the  complete  RFP.  An  Integrated 
Project  Team  (IPT)  should  be  responsible  for  performing  the  supporting  technical  analyses 
and  developing  the  required  specifications  that  will  be  included  in  the  RFP.  Section  C 
{Statement  of  Work  and  Specifications)  of  the  RFP  would  identify  the  product  line  related 
tasks  to  be  performed  by  the  contractor(s) — commensurate  with  the  chosen  acquisition 
strategy — and  include  the  performance  specifications  for  the  avionics  software  product(s)  to 
be  developed.  Developing  robust  specifications  and  a  comprehensive  RFP  are  critical  to  the 
success  of  the  entire  project.  They  can  substantially  reduce  the  risk  of  having  to  amend  the 
solicitation,  which  can  otherwise  result  in  a  long  and  protracted  contract  award. 
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6  Acquisition  Strategy  Risk  Mitigation 


There  are  obvious  benefits  and  risks  to  each  of  the  candidate  approaches.  However,  several 
concerns  surfaced  in  this  case  study:  “Can  a  contractor  other  than  the  original  developer 
successfully  replicate  the  System  A  software  (i.e.,  redevelop  the  software  from  the  original 
source  code1)  commensurate  with  a  product  line  approach  and  modem  software  practices?” 
and  “Can  measures  be  taken  to  insure  that  if  a  contractor  falters  it  can  be  detected  in  the  early 
stages  of  development  before  a  substantial  amount  of  funds  have  been  expended?”  From  the 
SPO’s  perspective,  this  was  the  essence  of  the  risk  of  adopting  a  product  line  approach — 
especially  when  considering  a  competitive  acquisition. 

Fortunately,  there  are  innovative  measures  that  can  be  taken  to  mitigate  these  risks  and  allay 
any  concerns  of  being  irreversibly  trapped  into  one  course  of  action  should  a  contractor  falter. 
Some  of  these  are  presented  below: 

•  Negotiate  a  first  task-order2  under  each  contract  concurrent  with  contract  award  for  a 
relatively  small  sum  corresponding  to  the  declared  contract  minimum. 

•  Include  a  number  of  pivotal  tasks  in  this  first  task-order  that  will  demonstrate  the 
contractor’s  ability  (or  inability)  to  perform  the  critical  tasks  required  to  mitigate  high 
risk  items  that  are  of  particular  concern  to  the  SPO. 

•  Specify  tasks  in  the  first  task-order  that  will  result  in  tangible  deliverables  that  can  be 
evaluated  by  a  technical  agent  of  the  contracting  organization  to  determine  their 
suitability  or  unsuitability. 

•  After  evaluating  the  incremental  deliverables  produced  under  the  first  task-order, 
decide  whether  another  follow-on  task-order,  similar  to  the  first,  should  be  initiated 
before  fully  committing  the  SPO’s  resources  to  the  current  acquisition  strategy. 

These  measures  can  be  applied  to  any  of  the  candidate  courses  of  action3  as  long  as  they  are 
ID/IQ  task  order  contracts.  It  should  be  noted  that  the  government  always  has  the  right  to 
terminate  a  contract  either  on  the  basis  of  termination-for-convenience4  or  termination-for- 
default.5  In  the  risk  mitigation  scenario  outlined  above,  the  government  doesn’t  need  to 


1  The  original  source  code  is  reported  to  be  a  combination  of  JOVIAL  and  assembly  language. 

2  The  government  does  not  have  to  commit  to  give  a  contractor  more  than  one  task  order. 

3  It  may,  however,  be  more  difficult  to  negotiate  such  an  agreement  for  a  sole  source  acquisition. 

4  Termination-for-convenience  is  known  as  “T  for  C”  and  is  invoked  when  the  objective  is 
determined  to  be  unachievable  because  of  problems  due,  at  least  partially,  to  the  government.  In 
these  cases  the  government  must  reimburse  the  contractor  for  the  effort  that  has  already  been 
expended. 

5  Termination-for-default  is  known  as  “T  for  D”  and  can  be  invoked  if  it  has  been  determined  that  the 
contractor  can’t  meet  the  requirements.  The  amount  of  money  the  contractor  is  entitled  to  may  be 
negotiated  at  the  discretion  of  the  contracting  officer  but  it  will  not  exceed  the  cost  of  the  effort  that 
has  already  been  expended. 
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terminate  the  contract  should  a  problem  arise.  The  government  is  only  obligated  to  fund  the 
minimum  task  order  that  the  contract  specifies.  This  can  be  defined  in  terms  of  some 
minimum  dollar  amount,  a  number  of  discrete  tasks  and  deliverables,  or  hours  of  effort 
commensurate  with  the  program’s  resources  and  risk  management  approach.  By  performing 
the  initial  task  order(s),  the  contractor  can  conclusively  demonstrate  its  ability  to  perform 
crucial  tasks  and  mitigate  high  risk  items  without  requiring  the  government  to  irrevocably 
commit  its  resources  up-front.  If  approved,  the  acquisition  team  would  incorporate  these 
measures  into  the  acquisition  strategy. 
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7  Summary 


We  have  outlined  the  approach  that  one  DoD  organization  used  to  develop  an  acquisition 
strategy  for  acquiring  a  software  product  line  to  eliminate  the  need  to  maintain  two 
independent  baselines  and  pay  twice  for  developing  new  software  capabilities.  The  approach 
used  consists  of  seven  steps  that  other  organizations  potentially  can  adapt  to  develop  their 
own  acquisition  strategy. 

As  part  of  this  effort,  the  acquisition  team  analyzed  four  basic  acquisition  approaches  and 
five  candidate  courses  of  action  leading  to  management’s  selection  of  an  acquisition  strategy. 
These  candidate  COAs  could  potentially  apply  to  any  acquisition  strategy  used  to 
commission  a  software  product  line.  The  case  study  includes  an  innovative  risk  mitigation 
approach  that  is  also  suitable  for  any  acquisition  strategy  using  an  ID/IQ  contract. 
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Feedback  and  Contact 


Comments  or  suggestions  about  this  document  or  the  series  of  technical  notes  on  software 
product  line  business  and  acquisition  guidelines  are  welcome.  We  want  to  meet  the  needs  of 
DoD  and  government  personnel  involved  in  the  business  and  acquisition  aspects  of 
implementing  software  product  lines.  To  that  end,  comments  concerning  this  technical  note, 
inclusion  of  other  topics,  or  any  other  issues  or  concerns  will  be  of  great  value  in  continuing 
this  series.  Comments  or  suggestions  should  be  sent  to 

Linda  Northrop,  Director 
Product  Line  Systems  Program 
lmn@sei.cmu.edu 


Software  Engineering  Institute 
Carnegie  Mellon  University 
Pittsburgh,  PA  15213 
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